The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
A component is a module of code for performing one or more tasks within a software application or service. The task performed by a component may involve generating a user interface, or may involve operations, such as playing a sound or a movie, that do not involve the generation of a user interface. Typically, components have several properties. For example, an audio format configuration component may have a sampling rate property, an encoding scheme property, etc.
Some operating systems may include a facility, referred to herein as a component manager, that discovers installed components. When there is a need for a particular type or subtype of a component, the component manager may search for and provide a list of all installed discovered components of the designated type or subtype.
An instance of a component is referred to herein as a “component instance”. Component instances have the properties of the component of which they are an instance. Thus, an instance of the audio format configuration component described above would have a sampling rate property and encoding scheme property. In addition, component instances typically have specific values assigned to those properties. For example, an audio format configuration component instance could have a sampling rate of 44.1 kHz, and an encoding scheme of MP3.
The interrelationships between the properties of a component may be complex. Components typically implement logic that constitutes a state machine for making the changes necessitated by the interrelationships. For example, in response to changing the value of one property of a component instance, the state machine of the component instance may cause the values of one or more interrelated properties of the component instance to change. The changes to the values of the interrelated properties may then cause even more property values to change. Thus, a single change to the value of a single property of a component instance may set off a chain reaction in which the values of any number of properties are changed.
Certain software modules may be interested in the values of properties of a component instance. Such modules are referred to herein as “interested modules”. The specific properties in which an interested module has an interest are referred to herein as “properties of interest”.
Interested modules themselves may or may not be components. For example, an interested module may be a User Interface (UI) module that displays the values of some or all of the properties of a component instance. In this example, the properties of interest would be the properties whose values are displayed by the UI. The UI module needs to know the current values of the properties of interest, so that the values that are displayed in the UI are kept current.
To ensure that the values displayed in the UI are kept current, the UI module may be designed with logic to know the circumstances under which the values for those properties will change. Thus, a developer who tries to implement a custom UI for a particular component needs to be aware of which values of which properties of the component instance trigger changes to which other properties of the component instance. Furthermore, the developer needs to be aware whether any properties that are changed as a result of changes to other properties are relevant to the properties that need to be included in the custom UI. This problem has a particular significance for implementations that need to rely on existing components, which are very complex and which include many properties and routines. Given the potential complexity of components, it may not be practical for interested modules to include such logic.
For example, a standard audio format configuration component may be used for encoding, decoding, or transcoding from one audio format (such as, for example, a file, a live input, or a network feed) to another format (which can be saved to a file or streamed out for a live broadcast and never saved to disk). Such encoding, decoding, or transcoding operations are very complex, as the properties of the starting audio format and the capabilities of the destination audio format can restrict one another. In this example, if a developer tries to implement a custom UI by using the standard audio configuration component, the developer needs to know and account for all the intricate property interrelatioships associated with the various audio encoding schemes. Furthermore, given the complexities of the standard audio format configuration component, it may not be practical for the custom UI to include logic that accounts for the circumstances under which the values for the different properties associated with the various audio encoding schemes change.
As an alternative, the interested module may be designed to periodically poll the component instance, to determine the current values of the properties of interest. However, polling is also not practical, since frequent polling of rarely changed property values is wasteful, and infrequent polling of frequently changed property values results in inaccuracies. Specifically, in order to determine whether a particular property of a component instance has changed, the property must be polled even though an actual change to the property may not have occurred. For example, if the value of another property, which may trigger a change to the particular property, is such that an actual change to the particular property has not occurred, the particular property must still be polled, which results in wasting time and computing resources.
Based on the foregoing, there is a clear need for a mechanism that allows interested modules to keep track of the current values of properties of interest without the overhead of polling, and without the need to understand the potentially complex interrelationships between component properties.